home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93a.txt / 000055_icon-group-sender _Mon Jan 18 01:16:44 1993.msg < prev    next >
Internet Message Format  |  1993-04-21  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Sat, 30 Jan 1993 20:39:53 MST
  2. Path: ucbvax!dog.ee.lbl.gov!overload.lbl.gov!agate!ames!haven.umd.edu!uunet!mercury.hsi.com!mlfarm!cs.arizona.edu!icon-group
  3. From: reid@vtopus.cs.vt.edu (Thomas F. Reid)
  4. Newsgroups: comp.lang.icon
  5. Subject: Re: endtab/detab
  6. Message-Id: <9301180116.AA05090@vtopus.cs.vt.edu>
  7. Date: 18 Jan 93 01:16:44 GMT
  8. Lines: 32
  9. In-Reply-To: <199301161259.AA02671@cheltenham.cs.arizona.edu> from "Ralph Griswold" at Jan 16, 93 05:59:45 am
  10. Apparently-To: icon-group@cs.arizona.edu
  11. Status: R
  12. Errors-To: icon-group-errors@cs.arizona.edu
  13.  
  14. > However, once you have a large user community and widely distributed
  15. > documentation, it's not feasible to remove something, even if it's
  16. > little used.  Worse, it's not feasible to redesign something that
  17. > was done badly.  That's one of the reasons language design is so
  18. > hard; once you've done it, implemented it, documented it, and
  19. > released it, you're stuck with it.
  20. >     
  21. > Ralph E. Griswold            ralph@cs.arizona.edu
  22. > Department of Computer Science          uunet!arizona!ralph
  23. > The University of Arizona        602-621-6609 (voice)
  24. > Tucson, AZ 85721            602-621-9618   (fax)
  25. > 
  26. I think that a change of paradigm is needed for language design.  I
  27. believe that the language designer should be encouraged to release a new
  28. language design and implementation every (say) 5-8 years along with a
  29. translator to/from the new/old versions.
  30.  
  31. This way, the language designer can correct old mistakes and extend the
  32. language "right" into new concepts without paying too much homage to the
  33. cursed god of upward compatibility.  There have been too many elegant
  34. languages ruined by trying to extend them into areas that the original
  35. design cannot comfortably permit.  Modula-2 comes to mind.
  36.  
  37. If the two versions are fundamentally the same, then the delta between
  38. implementations and the to/from translators should be straightforward.
  39. It is extra work for the language designer, but it has the reward of
  40. allowing the language to evolve gracefully rather than stagnate or accept
  41. awkward extensions.
  42.  
  43. Whatcha think?
  44.  
  45. Tom 
  46.